The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.
In multi-tenant database systems, such as the salesforce.com service, a multi-tenant architecture is used wherein users or customer organizations (i.e., tenants) share database resources that are organized as one logical database. The database tables themselves are typically shared and logical structures are employed to ensure differentiation and security among the different tenants. For example, each entity in the data model typically contains an organization_id column that distinguishes rows for each tenants. All queries and data manipulations for a tenant use a filter on this indexed column to ensure proper security and the appearance of virtual private databases. The data structure can be used to expose standard entities, such as Account, Contact, Lead, and Opportunity entities to customers.
In a multi-tenant database system, there are typically various applications and processes that are exposed to users through multiple modes of operation. For example, interfacing to the system applications could accomplished through user interfaces (UI), application program interfaces (API), or other development platforms that allow developers to access back-end processes and client-server interfaces. Each of these interfaces represents a different mode of operation. Oftentimes, these applications and processes are required to be tested for all the different supported modes of operation to ensure proper operation across all possible operational modes. In a traditional testing approach, a system administrator or other personnel needs to create test automation for those each of these different modes of operation independently. This results in the replication of the same test scenarios across multiple test suites for different operations, which results in an increase in the effort of test automation and in the deployment and use of redundant test code.
Accordingly, it is desirable to provide techniques enabling efficient testing of multi-tenant database components for different operational modes.